Summary

PostgreSQL has no scalar DAY / MONTH / YEAR functions — date parts are read via
EXTRACT(field FROM source). When transpiling from a dialect that does have them (e.g.
T-SQL), SQLGlot emitted the functions unchanged, producing invalid Postgres SQL.

This adds Postgres generator rules so exp.Day / exp.Month / exp.Year render as
EXTRACT(<part> FROM ...).

Reproduction

import sqlglot

# Before
sqlglot.transpile("SELECT DAY(d) FROM t", read="tsql", write="postgres")[0]
# -> 'SELECT DAY(d) FROM t'            # invalid: no DAY() function in Postgres

# After
# -> 'SELECT EXTRACT(DAY FROM d) FROM t'

MONTH and YEAR behave the same. EXTRACT is the standard Postgres construct for these
parts: https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT

Approach

• The fix is generator-only: T-SQL already parses these into the dedicated exp.Day /
  exp.Month / exp.Year nodes, so only the Postgres output was wrong. Parsing and other
  dialects are untouched (tsql -> tsql still yields DAY(d)).
• Rendering reuses the existing exp.Extract node rather than hand-built SQL, and the three
  rules share a small _extract_sql(part) factory in the style of the neighboring
  _date_add_sql(kind) helper.
• Dialects that inherit the Postgres generator (Redshift, Materialize, RisingWave) also benefit;
  they likewise lack scalar DAY/MONTH/YEAR.

Test

tests/dialects/test_postgres.py::TestPostgres::test_extract_date_parts asserts the
T-SQL -> Postgres transpilation and that the EXTRACT form round-trips in Postgres.

Fixes #6220